Repository navigation
ci: speed up the Windows jobs - #5808
Merged
Merged
Conversation
This was referenced Oct 25, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5808 +/- ##
==========================================
+ Coverage 76.09% 76.12% +0.02%
==========================================
Files 528 528
Lines 19579 19579
Branches 3829 3829
==========================================
+ Hits 14899 14904 +5
+ Misses 3794 3792 -2
+ Partials 886 883 -3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ric-oliv
force-pushed
the
ci/speed-up-windows-jobs
branch
from
October 25, 2026 16:22
d4f0e61 to
d673987
Compare
ric-oliv
force-pushed
the
ci/stop-installing-what-jobs-dont-use
branch
from
October 25, 2026 16:22
692022a to
b13062d
Compare
ric-oliv
marked this pull request as ready for review
October 26, 2026 19:04
ric-oliv
force-pushed
the
ci/stop-installing-what-jobs-dont-use
branch
from
October 26, 2026 19:15
b13062d to
881636f
Compare
ric-oliv
force-pushed
the
ci/speed-up-windows-jobs
branch
from
October 26, 2026 19:15
d673987 to
7fa3c1e
Compare
github-actions
Bot
added
risk: high
Base automatically changed from
ci/stop-installing-what-jobs-dont-use
to
main
October 27, 2026 00:41
msbuild.exe builds on one node unless it gets -m, while the dotnet CLI passes -maxcpucount on its own. The MSBuild job's binlog shows 21.4 minutes on one node, 12.4 of them in Build. The win-x64 leg builds the same solution filter with dotnet build in 3 to 4.5 minutes. -nr:false keeps the worker nodes from staying around after the build, since nothing later in the job uses them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Windows .NET legs spent about 12 minutes in Setup Environment and Restore, against about 4.5 on Linux. setup-dotnet installed into C:\Program Files\dotnet, where the SDK installs workloads as MSI packages, and NuGet extracted packages into the user profile on C:. On Windows, Setup Environment now starts by installing .NET and the NuGet cache next to the workspace, where workloads install as plain files. On the x64 runners that's on D:. The arm64 runners have no D:, so there the NuGet packages and TEMP go on a Dev Drive, and .NET stays next to the workspace on C:. Trusting the new drive is retried. If setting it up fails anyway, the step warns and keeps the NuGet packages next to the workspace, because the drive is a speedup. Every Windows job that uses Setup Environment gets it. There ~/.nuget/packages isn't the NuGet cache anymore, so the integration tests now clear the Sentry packages they push from NUGET_PACKAGES when it's set. In two probes of the win-arm64 leg, the job took 33.8 and 32.4 minutes with the Dev Drive, against 37.2 and 35.8 without it, and 36.9 with .NET on the drive too. On its own, the step took the MSBuild job's Run MSBuild from 23-24 to 14.7 minutes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ric-oliv
force-pushed
the
ci/speed-up-windows-jobs
branch
from
October 27, 2026 08:35
7fa3c1e to
455b362
Compare
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
The MSBuild job ran msbuild -t:Restore,Build,Pack. NuGet's docs say restoring and building in one invocation is unpredictable and often wrong: restore can bring in props and targets from packages, so the build needs its own evaluation after it. -restore runs the restore as a separate pass first, which is what the dotnet CLI does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
github-actions
Bot
added
risk: medium
bitsandfoxes
approved these changes
Oct 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 2 of 6 for #5806. #5807 is merged. The Windows jobs spent much longer than Linux in setup, restore and the MSBuild job, for two reasons, one commit each.
Build the MSBuild job on all cores.
msbuild.exebuilds on one node unless it gets-m, while thedotnetCLI passes-maxcpucounton its own. The MSBuild job's binlog showed 21.4 minutes on a single node.-nr:falsekeeps the worker nodes from staying around after the build, since nothing later in the job uses them. In #5796 the job took 26.0 minutes against 29.6 to 30.3, with the same 44 warnings and 49 packages as a single-node build.Install .NET and NuGet packages on a faster drive. The Windows images keep .NET under
C:\Program Files\dotnet, where workloads install as MSI packages, and NuGet extracts packages into the user profile onC:.D:.C:, so there the NuGet packages and TEMP go on a Dev Drive. Trusting a freshly mounted Dev Drive can fail with "Access is denied" while the volume is still busy, so the action retries it. If setting up the drive fails anyway, the action warns and keeps the NuGet packages next to the workspace, so the job still runs, just slower.NUGET_PACKAGESwhen it's set, since~/.nuget/packagesisn't the cache there anymore.What #5782 and the probes #5798 and #5801 measured:
C:\andD:\.On this PR's own CI
3 runs, including #5807, against
mainat b41b96c. The MSBuild job took 15.3, 14.4 and 14.8 minutes against 29.5, with Run MSBuild at 10.3 to 10.6 against 22.5. win-x64's Restore took 0.8 to 1.1 minutes against 6.0, and win-arm64's 2.2 to 2.8 against 4.0. win-arm64's Setup Environment stayed at 4.7 to 5.2. The whole stack's numbers are in #5806.#skip-changelog